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(54) Wireless access to embedded networks 

(57) A method and system Is provided for a protocol 
translation device that may include two different proto- 
cols and an intermediate, network- in dependent proto- 
col. In an embodiment of the invention, an emerging 
worldwide standard, Bluetooth, provides a wireless in- 



terface to the electronics in an automotive vehicle via 
the de-facto standard for vehicle buses, Controller Area 
Network (CAN). A remote application can connect to this 
interface via a Bluetooth host in the vehicle or in com- 
munication range of the vehicle. 
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Field of the Invention 

[0001] The present invention relates to a protocol 5 
translation device. More specifically, a protocol transla- 
tion device is provided that can be used for automotive 
diagnostic purposes as well as other purposes. 

Background Information 10 

[0002] Access to in-vehicle electronics is known in the 
art. Access to in-vehicle electronics currently requires 
special hardware that is connected directly to the vehicle 
bus through an OBDII (On-Board Diagnostic) connector '5 
or some other physical connection. Further, hardware 
that is dedicated to a certain kind of wireless link (e.g., 
Groupe Special Mobile (GSM) phone) has been pro- 
posed for remote diagnosis. 

[0003] There are several inherent problems with the 20 
current method of accessing in-vehicle electronic infor- 
mation. One problem is the amount of time it can take 
to attach the OBDII connector. Also, it may be difficult 
to find the OBDII connector within the engine bay or in 
another spot in the vehicle if one is not entirely familiar 25 
with the layout of the car, adding to the total time ex- 
hausted. 

[0004] Another problem with the current method of at- 
tachment to the in-vehicle electronics is the limitation 
upon freedom of movement for the operator. With the 30 
connector attached to the vehicle, the operator is forced 
to avoid the connector line as he moves around the ve- 
hicle while repairing the vehicle, etc. This could affect 
an operator's efficiency. There could also be a hazard 
of tripping over the wire as the operator moves back and 35 
forth around the vehicle. 

[0005] Further, another limitation of the prior art is the 
necessity for the presence of the vehicle for physical at- 
tachment to the operator's equipment. In order to ac- 
cess the in-vehicle electronics, an actual physical con- *o 
nection must be made. This can be inconvenient for the 
vehicle owner. Also, in the case of a mechanic's usage 
of the prior art for access to in-vehicle electronics, a 
problem exists diagnosing intermittent problems and 
problems occurring only during vehicle operation. With *s 
the prior art, a vehicle's electronics cannot be accessed 
in real time while the car is in motion. 
[0006] By providing a means to access the vehicle 
electronics without the requirement of a physical con- 
nection, the present invention eliminates the above- 50 
mentioned problems. In view of the above and for other 
reasons, there is a need for a system and method that 
provides wireless access to a bus, such as that provided 
in an automobile. 

55 

Summary of the Invention 

[0007] A protocol translation device is disclosed that 
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may include two different^i^^ols and an intermediate, 
network-independent protocol. In one embodiment of 
the invention, an emerging worldwide standard, Blue- 
tooth, created by the Wireless Personal Area Network 
(WPAN) Working Group (IEEE 802.15), provides a wire- 
less interface to the electronics in the vehicle via a Con- 
troller Area Network (CAN). CAN is an international 
standard documented in ISO 11898 (for high-speed ap- 
plications) and ISO 11519 (for lower-speed applica- 
tions). A remote application can connect to this interface 
via a Bluetooth host in the vehicle or in communication 
range of the vehicle. Such a Bluetooth host could be a 
mobile phone or an onboard computer. 
[0008] According to an embodiment of the present in- 
vention, a protocol translation can occur from Controller 
Area Network (CAN) protocol to Bluetooth protocol, and 
the signal in the Bluetooth protocol can then be trans- 
mitted from the vehicle's electronic systems' bus to an 
external receiver via a wireless link. 
[0009] Such an interface would enable external devic- 
es to subscribe to certain signals on the vehicle bus or 
interrogate a vehicle's electronic control units (ECUs) 
without interfering with the vehicle's operation. 
[0010] Aftermarket products are emerging that notify 
other drivers of traffic conditions such as traffic jams and 
accidents. These systems could be greatly enhanced if 
they had access to data on the vehicle bus, as this would 
improve the system's knowledge about the state of eve- 
ry participating vehicle. 

Brief Description Of The Drawings 

[0011] 

Figure 1 shows a block diagram of protocol trans- 
lation according to one possible embodiment of the 
present invention. 

Figure 2 shows an embodiment of the protocol 
translation system of Figure 1 operating in an auto- 
motive environment. 

Figure 3 provides a block diagram of a specific 
CAN-to-Bluetooth embodiment of the present in- 
vention. 

Detailed Description 

[0012] Figure 1 shows a block diagram of the protocol 
translation according to an embodiment of the present 
invention. A first driver, which is denoted in the embod- 
iment of Figure 1 as the 'in' side of the Network Driver 
1 00, receives a message of a first protocol from a given 
network for translation. The Network Driver 100 first 
converts the received message of the first protocol to a 
new, network-independent protocol. The Network Driver 
1 00 then passes the message to a Message Dispatcher 
102 whereupon the Message Dispatcher 102 consults 
a Rules Database 104 to determine which Message 
Handler 1 06 out of a plurality of Message Handlers 1 06 
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to forward the network-inlfpendent message. The 
Message Handler 106 fills the destination fields of the 
message. The Message Handlers 106 utilize special- 
ized packet translation involving address changes, net- 
work changes segmentation/desegmentation, etc. The 5 
Message Handlers 106 further provide accessibility of 
external applications for signal extraction, etc. 
[0013] The Message Handler 106 involved in the 
transfer then forwards the message to a Network Multi- 
plexer 108, which consults the address and network 10 
fields of the network-independent message to identify 
the destination network. A Network Configuration Unit 
1 1 0 is utilized by the Network Multiplexer 1 08 to config- 
ure and connect the gateway software components for 
such things as system startup and maintenance and for *5 
dynamic reconfiguration. 

[0014] The Network Multiplexer 108 then passes the 
network-independent message to a second driver, 
which is denoted as the 'out 1 side of the Network Driver 
1 00. The Network Driver 1 00 then converts the network- 20 
independent message to a second protocol. The mes- 
sage is forwarded on from the Network Driver 100 to a 
third driver, called External Driver 112, from which the 
message is utilized by a remote host of some type. 
[0015] Figure 2 showsthis protocol translation system 25 
operating in an automotive environment. In the depicted 
embodiment, the vehicle bus 200 within the vehicle 202 
provides a pathway for data communication between 
various electronic components located throughout the 
vehicle. The data being passed upon the vehicle bus is 30 
accessed by a first network driver, which, similar to Fig- 
ure 1 , is denoted as 'Network Driver - in' 100. The data 
message received by Network Driver 100 is converted 
to a network-independent protocol, as is stated above, 
and then the message is passed to a Message Dis- 35 
patch er 1 02, which utilizes a Rules Database 1 04 to de- 
termine which Message Handler 1 06 should receive the 
message. As stated previously, upon receipt of the net- 
work-independent message, the Message Handler 1 06 
fills the destination fields of the message and utilizes *o 
specialized packet translation involving address chang- 
es, network changes segmentation/desegmentation, 
etc. 

[0016] The Message Handler 106 forwards the net- 
work-independent message to a Network Multiplexer *s 
108, which consults the address and network fields of 
the message to identify the destination network. As stat- 
ed above, a Network Configuration Unit 110 is utilized 
by the Network Multiplexer 1 08 to configure and connect 
the gateway software components for such things as so 
system startup and maintenance and for dynamic 
reconfiguration. 

[001 7] The Network Multiplexer 1 08 then passes the 
network-independent message to a second driver, 
which is denoted as 'Network Driver - out' 1 00. The Net- 55 
work Driver 1 00 then converts the network-independent 
message to a second protocol. The message is forward- 
ed on from the Network Driver 1 00 to a third driver, called 
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the message is utilized 



External Driver 112, fron 
by a Remote Computer 204. 

[0018] Figure 3 provides a block diagram of a specific 
CAN-to-Bluetooth embodiment of the present invention. 
As is previously stated, the present invention concerns 
a node in an in-vehicle bus network that comprises gate- 
way functionality for passing messages from the in-ve- 
hicle bus to a remote host, and a wireless communica- 
tion chipset for establishing, maintaining, and controlling 
a wireless link between the node and one or several re- 
mote hosts. In the following, the invention is described 
for a CAN as the in-vehicle communication protocol and 
Bluetooth as short-range wireless communication 
standard. Figure 3 depicts the core concept of this em- 
bodiment of the present invention. 
[0019] The CAN-Bluetooth gateway node (CBGWN) 
307 includes a Bluetooth host 305 and Bluetooth hard- 
ware 306 connected via a host controller interface (HCI) 
304. The Bluetooth host comprises a CAN controller 
301 , a remote service controller (RSC) 302, a protocol 
converter 303, and a host controller interface device 
304. The Bluetooth hardware 306 enables a wireless 
link to other Bluetooth hardware (309.1... 309. n) con- 
nected to Bluetooth hosts (308. 1... 308. n) via an HCI. 
This setup enables a remote application, which does not 
necessarily reside on any of the remote Bluetooth hosts 
(308.1... 308. n), to communicate with the RSC 302. 
Such a remote application could be a diagnosis program 
on a server that is linked to the CBGWN through a mo- 
bile phone that is one of the Bluetooth hosts (308.1... 
308.n). 

[0020] The CAN controller 301 controls the commu- 
nication with the Vehicle Bus 200 (Figure 2). Signals 
contained in CAN messages that pass the acceptance 
filter of the CAN controller 301 are passed on to the pro- 
tocol converter 303. The protocol converter 303 re- 
trieves CAN signals from CAN messages, computes the 
actual physical value of signals such as speed or RPM 
(typically by applying a scaling factor), and then puts 
them in the payload of the target protocol's protocol data 
units (PDUs). In an advantageous implementation, the 
CAN signals are directly assigned to data packets that 
can be sent via the host controller interface (HCI) to the 
Bluetooth host controller. The RSC 302 controls which 
signals are put in the PDUs as described later. The gate- 
way functionality of the protocol converter also compris- 
es: the readressing (l:n) of messages based on sub- 
scriber management implemented in the RSC 302 (see 
below); the resequencing (i.e., changing the temporal 
order of received and retransmitted messages); and the 
changing of timing behavior. 

[0021] If a packet-switched connection exists be- 
tween CBWGN 307 and a remote application, the link 
between the CAN-connected Bluetooth host 305 and a 
remote Bluetooth host (308.1 ...308.n) is an asynchro- 
nous connection-less link (ACL link). Next, the CAN sig- 
nals are assigned to HCI ACL packets. Recommended 
Standard 232 (RS232) as specified by the Electrical In- 
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dustries Association (EIA) cWTd serve as the HCI trans- 
port layer, for example. It is possible to assign one PDU 
to each incoming CAN message, one PDU to each in- 
coming signal, and one PDU to several incoming CAN 
messages and signals. 5 
[0022] The data rate and the throughput of the wire- 
less link are among the factors that determine the allo- 
cation procedure. 

[0023] In this embodiment, no remote application that 
connects to the CBGWN 307 has direct access to the 10 
CAN in the vehicle. This means, no remote application 
can generate CAN messages. Yet, to go beyond the ca- 
pability of passively listening to bus traffic, the transmis- 
sion of CAN messages by the CBGWN 307 is supported 
as follows: The RSC 302 stores a predefined set of CAN 15 
messages that the CAN gateway node can transmit on 
the bus, along with the identifiers and rules for the mes- 
sages that are allowed to be transmitted (e.g. debounce 
time for event-triggered messages and period for peri- 
odic messages). This ensures that the worst-case bus 20 
load can be analyzed without any knowledge of future 
remote applications. CAN messages that the CBGWN 
307 is allowed to transmit would typically include chal- 
lenge-response message schemes for diagnosis. When 
such a message is sent to an ECU, the ECU sends a 25 
reply containing failure codes or more generally, certain 
data from its memory. To initiate the transmission of 
challenge-response messages, a remote application 
sends a request via a remote Bluetooth host (308.1... 
308. n) to the RSC 302. After authenticating and author- 30 
izing the remote application (see below), the RSC 302 
initiates the transmission of the messages via the CAN 
controller 301 . Also, the RSC 302 notifies the protocol 
converter 303 to assign the signals contained in the re- 
sponse messages to PDUs to be passed on to the re- 35 
mote application. 

[0024] The protocol converter 303 has a-priori knowl- 
edge of the start bits and length of the signals in each 
received CAN message that can pass the acceptance 
filter and assigns them to PDUs that can be interpreted *o 
by the remote Bluetooth host (308.1 ...308.n). For this 
purpose, in the CBWGN, a list is stored of CAN mes- 
sages and the signals contained therein as well as the 
corresponding PDUs of the target protocol: 
[0025] In an advantageous implementation, each re- 45 
mote host (308.1 ...308.n) is authenticated by the RSC 
302. In an authorization procedure, the RSC 302 verifies 
the subscription privileges of the remote application (not 
necessarily the remote host). The subscription privileg- 
es concern the list of signals to which a remote applica- 50 
tion can subscribe. Also, the subscription privileges 
would indicate whether the remote application is al- 
lowed to initiate challenge-response schemes. The 
communication between the remote application and the 
RSC 302 can be encrypted independently of the encryp- 55 
tion functionality provided by Bluetooth. In an advanta- 
geous application, a public key encryption method is 
used, where the private key of the CBGWN 307 is stored 



in the CBGWN 307 and^BRnown to others. Remote 
applications that want to subscribe to messages must 
obtain the public key for the CBGWN 307, which gives 
a manufacturer some control of the subscribers. More- 
over, the public keys of the remote applications would 
need to be stored in the CBGWN 307, allowing only ap- 
plications that have the corresponding private key to 
communicate with the CBGWN 307. An alternative to 
this method would be a ticket-based authentication 
method such as Kerberos, a network authentication pro- 
tocol designed by Massachusetts Institute of Technolo- 
gy to provide strong authentication for client/server ap- 
plications by using secret-key cryptography. 
[0026] The CBGWN 307 is not necessarily a stand- 
alone ECU . The described functionality could be imple- 
mented in an existing ECU or in a distributed system. 
The overall vehicle bus architecture determines to which 
bus the CBGWN 307 should be connected. It is essen- 
tial that all data of interest are available to the CBGWN 
307. If these data originate from ECUsthat are connect- 
ed to a bus otherthan the bus to which the CBGWN 307 
is connected, a wireline-to-wireline gateway (e.g., 
CAN-CAN) between the two buses would ensure that 
the messages of interest are passed on to the CBGWN 
307. For example, if the GBGWN 307 is attached to the 
powertrain CAN and needs data from the airbag control- 
ler (e.g., for an accident notification application), a gate- 
way should exist between the powertrain CAN and the 
CAN to which the airbag controller is attached. 
[0027] Although several embodiments are specifically 
illustrated and described herein, it will be appreciated 
that modifications and variations of the present inven- 
tion are covered by the above teachings and within the 
purview of the appended claims without departing from 
the spirit and intended scope of the invention. 



Claims 

1 . A method for translating a message of a first proto- 
col received by a first driver to a second protocol 
transmitted by a second driver, comprising: 

converting the message received by the first 
driver to an independent format; 
transmitting the message from the first driver to 
a second driver via a message handler; and 
converting the message received by the sec- 
ond driver in the independent format to the sec- 
ond protocol; where 

the first driver and the second driver are located 
in a vehicle and the first protocol is a vehicular 
protocol; and 

the second protocol is a wireless link. 

2. The method of claim 1 , further comprising: 

receiving the message from the first driver by a 
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message dispatcrlF'before transmitting the 
message to a message handler, wherein the 
message dispatcher selects the message han- 
dier from a set of one or more message han- 
dlers by consulting a database. 

3. The method of claim 2, further comprising: 

receiving the message from the message han- 
dler by a multiplexer before transmitting the 
message to the second driver; 



driver back to the s^^^driver for translation and 
receipt at the first driver in the first protocol. 

16. The method of claim 15, wherein the third driver is 
5 unable to communicate with the second driver un- 
less the third driver adheres to predefined transmis- 
sion rules and transmits messages from only a pre- 
defined group of possible messages. 

10 1 7, A system for translating a message of a first proto- 
col to a second protocol, comprising: 



4. The method of claim 3, wherein the multiplexer uti- 
lizes a network configuration unit for at least one of 
system startup, maintenance, and dynamic recon- *5 
figuration. 

5. The method of claim 1 , further comprising: 

performing a manipulation on the message in 20 
the message handler. 

6. The method of claim 5, wherein the manipulation 
includes at least one of packet translation or inter- 
action with a computer application. 25 



a first driver to receive the message of the first 
protocol and convert the message to an inde- 
pendent format; 

a message handler to receive said message 
from said first driver; and 
a second driver to receive said message from 
said message handler and to convert the mes- 
sage received in the independent format to the 
second protocol; where 
the first driver and the second driver are located 
in a vehicle and the first protocol is a vehicular 
protocol; and 

the second protocol is a wireless link. 



7. The method of claim 1 , further comprising transmit- 
ting the message from the second driver to a third 
driver 

8. The method of claim 3, wherein the multiplexer is a 
network multiplexer. 

9. The method of claim 2, wherein the database is a 
rules database. 

1 0. The method of claim 1 , fu rther comprising transmit- 
ting the message from the second driver to the third 
driver in the second protocol by wireless communi- 
cation. 

11. The method of claim 1 , wherein the first protocol is 
a Controller Area Network protocol. 



18. The system of claim 1 7, further comprising: 

a message dispatcher to receive the message 
from the first driver before transmitting the mes- 
sage to the message handler, wherein the mes- 
sage dispatcher is adapted to the message 
handler from a set of one or more message 
handlers by consulting a database. 

19. The system of claim 1 8, wherein a multiplexer is to 
receive the message from the message handler be- 
fore transmitting the message to the second driver; 

20. The system of claim 19, wherein the multiplexer is 
to utilize a network configuration unit for at least one 
of system startup, maintenance, and dynamic 
reconfiguration. 
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1 2. The method of claim 1 , wherein the second protocol 
is a Bluetooth protocol. 

13. The method of claim 10, wherein the message re- 
ceived by the third driver is translated back to the 
first protocol and received by a fourth driver. 



45 21 . The system of claim 1 7, wherein the message han- 
dler is to perform a manipulation on the message. 

22. The system of claim 21 , wherein the manipulation 
includes at least one of packet translation and in- 
50 teraction with a computer application. 
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14. The method of claim 10, wherein a remote applica- 
tion in communication with the third driver is capa- 
ble of receiving the message. 

15. The method of claim 14, wherein the remote appli- 
cation is capable of either passively receiving the 
message or initiating a transmission from the third 



23. The system of claim 17, further comprising a third 
driver coupled to the second driver. 

24. The system of claim 19, wherein the multiplexer is 
a network multiplexer. 

25. The system of claim 1 8, wherein the database is a 
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26. The system of claim 1 7, wherein the message is 
transmitted from the second driver to a third driver 
in the second protocol by wireless communication. 

27. The system of claim 1 7, wherein the first protocol is 
a Controller Area Network protocol. 

28. The system of claim 17, wherein the second proto- 
col is a Bluetooth protocol. 

29. The system of claim 26, wherein the message re- 
ceived by the third driver is translated back to the 
first protocol and received by a fourth driver. 

30. The system of claim 26, wherein a remote applica- 
tion in communication with the third driver is capa- 
ble of receiving the message. 

31. The system of claim 30, wherein the remote appli- 
cation is capable of either passively receiving the 
message or initiating a transmission from the third 
driver back to the second driver for translation and 
receipt at the first driver in the first protocol. 



to 
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the network muHPfer is to utilize a network 
configuration unit for at least one of system 
startup, maintenance, and dynamic reconfigu- 
ration; 

the message handler is to perform a manipula- 
tion on the message that includes at least one 
of packet translation and interaction with a com- 
puter application; 

the message is transmitted from the second 
driver to the third driver in the Bluetooth proto- 
col by wireless communication; and 
a remote application in communication with the 
third driver is capable of either passively receiv- 
ing the message or initiating a transmission 
from the third driver back to the second driver 
for translation and receipt at the first driver in 
the Controller Area Network protocol. 



32. The system of claim 32, wherein the third driver is 
unable to communicate with the second driver un- 
less the third driver adheres to predefined transmis- 
sion rules and transmits messages from only a pre- 
defined group of possible messages. 

33. A system for translating a message of a Controller 
Area Network protocol to a Bluetooth protocol, com- 
prising: 
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a first driver to receive the message of the Con- 
troller Area Network protocol and convert the 
message to an independent format; 
a message handler to receive said message 
from said first driver; 

a second driver to receive said message from 
said message handler and to convert the mes- 
sage received in the independent format to the 
Bluetooth protocol; 

a message dispatcher to receive the message 
from the first driver before transmitting the mes- 
sage to the message handler, wherein the mes- 
sage dispatcher is adapted to the message 
handler from a set of one or more message 
handlers by consulting a rules database; and 
a third driver coupled to the second driver; 
where 

the first driver and the second driver are located 
in a vehicle; 

a network multiplexer is to receive the message 
from the message handler before transmitting 
the message to the second driver; 
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